Methods and apparatus for a secure sleep state

ABSTRACT

Methods and apparatus for a secure sleep state are disclosed. An example method includes, in response to an initiation of a sleep state of a computing platform, encrypting a memory of the computing platform; and decrypting the memory when resuming the computing platform from the sleep state, wherein placing the computing platform in the sleep state includes powering down a portion of the computing platform and preserving a state of the computing platform.

FIELD OF THE DISCLOSURE

This disclosure relates generally to power state management and, moreparticularly, to methods and apparatus for a secure sleep state.

BACKGROUND

Many computing platforms, such as desktop computers and laptops, can beplaced in one or more power states other than an ON state or an OFFstate. For example, some computing platforms can be placed in ahibernation state. Placing a computing platform in hibernation involvespowering down the system while preserving a state of the system (e.g.,by writing contents of Random Access Memory (RAM) to a hard disk).Alternatively, some computing platforms can be placed in a sleep state.Placing a computing platform in a sleep state involves cutting power tomany, but not all components of the system and preserving the state ofthe system. Typically, entering an ON state from the sleep state is lesstime consuming than entering the ON state from the hibernation state.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an example computing platform including anexample secure sleep state module disclosed herein.

FIG. 2 is a block diagram of a first example implementation of theexample decrypter of FIG. 1.

FIGS. 3A-3D are flowcharts representative of example machine readableinstructions that may be executed to implement the example secure sleepstate module of FIG. 1.

FIG. 4 is a block diagram of a second example implementation of theexample decrypter of FIG. 1.

FIG. 5 is a flowchart representative of example machine readableinstructions that may be executed to implement the example decrypter ofFIG. 4.

FIG. 6 is a block diagram of an example processing system capable ofexecuting the example machine readable instructions of FIGS. 3A-D toimplement the example secure sleep state module of FIG. 1 and/or theexample machine readable instructions of FIG. 5 to implement the exampledecrypter of FIG. 4.

DETAILED DESCRIPTION

Computing platforms such as desktop computers and laptops storeinformation that a corresponding user may deem secret, sensitive, and/orotherwise not fit for public access. Some computing platforms includefull disk encryption capabilities to protect such data when thecomputing platforms are placed in an OFF state (e.g., fully turned off)or a hibernation state (e.g., the system being powered down whilepreserving a state of the system). That is, unless the user has placedthe computing platform in an OFF state or a hibernation state,information on a lost or stolen computer can be accessed. However,having to place the computing platform in the OFF state or thehibernation state has drawbacks. For example, the OFF state does notpreserve the state of the computing platform and, thus, the user isforced to save all open document(s) (or other type of unsaved data) andexit all application(s) (or other type of program). Further, booting thecomputing platform from the OFF state requires a significant amount oftime and requires the user to reopen document(s) and/or application(s).In many instances, the user may have forgotten the state of thecomputing platform and/or be unable to navigate to the previous state ofthe computing platform. While the hibernation state preserves the stateof the computing platform, resuming from the hibernation state alsoconsumes a significant amount of time, especially on laptops, notebooks,netbooks, etc.

A sleep state, which is sometimes referred to as the S3 power state,avoids these drawbacks. For example, resuming from the sleep state isrelatively much faster than resuming from an OFF state or a hibernation(e.g., resuming from the sleep state can be substantially instant) andenables the user to immediately resume working on the open document(s)and/or application(s). However, sensitive information on a computingplatform in the sleep state is vulnerable to unwanted access (e.g., inthe case of a stolen or lost computing platform). For example, theDynamic Random Access Memory (DRAM) of a computing platform in the sleepstate can be accessed by moving the DRAM to another computer where theDRAM can be scanned. Alternatively, the DRAM of a computing platform inthe sleep state can be accessed by performing a cold boot attack.Moreover, if such an attack results in the attacker finding encryptionkeys in the DRAM, all data on the disk can be accessed.

Example methods, apparatus, and articles of manufacture disclosed hereinprovide a secure sleep state that provides protection of data stored ona computing platform while in a sleep state. As described in greaterdetail below, example methods, apparatus, and articles of manufacturedisclosed herein enable users to activate the secure sleep state suchthat each time a corresponding computing platform is placed in the sleepstate, data is encrypted. Further, example methods, apparatus, andarticles of manufacture disclosed herein detect when the computingplatform is taken out of the sleep state (e.g., into an ON state) and,in response, decrypts the secure data if the user provides the propercredentials. Thus, using the secure sleep state provided by examplemethod, apparatus, and articles of manufacture disclosed herein, userscan place the computing platform in the sleep state to avoid thedrawbacks of the OFF state and the hibernation, and at the same timeprotect the data stored on the computing platform from unwanted access.

FIG. 1 illustrates an example computing platform 100 in which examplemethod, apparatus, and/or articles of manufacture disclosed herein canbe implemented. FIG. 1 includes a Basic Input/Output System (BIOS) 102,an operating system (OS) 104, and DRAM 106. However, the examplecomputing platform 100 may include additional component(s), such asadditional or alternative types of memory, a network interface, databuses, processor(s), etc. In brief, the BIOS 102 boots the computingplatform 100 such that the operating system 104 can take control of, forexample, access to memory and execution of instructions (e.g., via aprocessor). In the illustrated example, the DRAM 106 implements the mainmemory of the computing platform used to store data associated with, forexample, executing application(s), documents, etc.

To provide the example computing platform 100 the secure sleep statedisclosed herein, the example BIOS 102 includes an example secure sleepstate module 108. Although implemented in the BIOS 102 in the example ofFIG. 1, the example secure sleep state module 108 can be implemented inconnection with additional or alternative components, such as anExtensible Firmware Interface (EFI). As described in greater detailbelow, the example secure sleep state module 108 of FIG. 1 detects whenthe computing platform 100 is being placed in a sleep state and, inresponse, encrypts the DRAM 106 such that the sleep state is secure(e.g., includes protection over the data of the DRAM 106). Further, asdescribed in greater detail below, the example secure sleep state module108 decrypts the DRAM 106 when the computing platform 100 is beingresumed from the secure sleep state.

In the illustrated example of FIG. 1, the secure sleep state module 108interacts with and/or utilizes a BIOS setup interface 110 to enable auser to activate the secure sleep state. The example BIOS setupinterface 110 of FIG. 1 is accessed by the user pressing a dedicated key(e.g., on a keyboard) while the platform 100 is booting. The exampleBIOS setup interface 110 presents a menu to the user including an optionto enable or activate the secure sleep state. In the example of FIG. 1,the option instructs the user to provide a passphrase (e.g., a passwordthat meets minimum security strength requirements as dictated by, forexample, rules stored in the BIOS 102) that the user will be required toenter when resuming the platform 100 from the secure sleep state. Whenthe secure sleep state is currently inactive or disabled, the userproviding the passphrase acts as the activation or enablement of thesecure sleep state. Additionally or alternatively, the example BIOSsetup interface 110 allows or requires (e.g., periodically) the user tochange the passphrase. The example BIOS setup interface 110 may alsoprovide the user with instructions and other information regarding thesecure sleep state and how to utilize the same. For example, the BIOSsetup interface 110 informs the user that the passphrase will need to beentered each time the platform 100 resumes (e.g., from the secure sleepstate). When a passphrase has been entered and/or the secure sleep stateis otherwise active, the BIOS setup interface 110 is protected fromaccess by, for example, requiring the user to enter the currentpassphrase before having access to the menu of the BIOS setup interface110.

The example secure sleep state module 108 includes a passphraseinterface 112 that receives and/or otherwise obtains the passphraseentered by the user into the BIOS setup interface 110. The examplepassphrase interface 112 hashes the passphrase (e.g., performs a hashfunction on the passphrase) and stores a resulting hash value 114. Inthe illustrated example, the passphrase itself is not stored. Instead,the stored hash value 114 represents the passphrase according to thehash function that was performed on the passphrase. The example securesleep state module 108 includes an encrypter 116 that utilizes thestored hash value 114 to encrypt data of the DRAM 106. In particular,the example encrypter 116 includes a key generator 118 that generates awrapping key using the stored hash value 114. The example key generator118 also generates an encryption key using, for example, a random numbergenerator in conjunction with an encryption engine. Having generated awrapping key from the stored hash value 114 and a random encryption key,the example key generator 118 of FIG. 1 wraps the random encryption keyin the wrapping key. A BIOS memory 120 (e.g., System Management RandomAccess Memory (SMRAM)) is used to store the wrapped encryption key 122and the encryption key 124. The example BIOS memory 120 of FIG. 1 isimplemented by flash memory. As described above, the passphrase isdestroyed (e.g., not stored). Further, the wrapping key 122 used to wrapthe encryption key 124 is also destroyed. As described below, theencryption key 124 is used to protect the data of the DRAM 106 whenentering the secure sleep state and the wrapped encryption key 122 isused to provide access to the protected DRAM (e.g., to an authorizeduser) when resuming from the secure sleep state.

After the passphrase is provided to activate the secure sleep state, theBIOS 102 passes control to the OS 104. The OS 104 controls the platform100 during normal operation, during which data of the DRAM 106 is likelymodified (e.g., in response to execution of application(s) andassociated document(s)). The OS 104 continues to control the platformuntil, for example, the user initiates a sleep state. The user caninitiate a sleep state by, for example, closing a lid of the platform(e.g., when the platform 100 is implemented by a laptop computer),pressing a power or sleep button, or selecting the sleep state from amenu managed by the OS 104. Alternatively, the sleep state can beinitiated in response to a period of inactivity. In the illustratedexample of FIG. 1, the action taken by the user to initiate the sleepstate (e.g., closing a lid or pressing a button) or the period ofinactivity generates a System Control Interrupt (SCI) that isintercepted by the OS 104 and/or results in a function call (e.g., viaselecting a menu option dedicated to the sleep state) to the OS 104. Inthe example of FIG. 1, the OS 104 includes a sleep state detector 126representative of the detection of the user initiating the sleep stateon the platform 100. In response to the sleep state detector 126determining that the sleep state has been initiated, the OS prepares theplatform 100 for the sleep state and writes a value to a dedicatedAdvanced Configuration and Power Interface (ACPI) register. In theillustrated example, writing to the ACPI causes an interrupt generator128 to generate a System Management Interrupt (SMI) corresponding to thesleep state initiation.

The example secure sleep state module 108 includes an SMI handler 130(e.g., a handler dedicated to the type of interrupt generated by theinterrupt generator 128) that responds to the SMI generated by theinterrupt generator 128 of the OS 104. The example SMI handler 130 ofFIG. 1 determines whether the secure sleep state is enabled by, forexample, checking if a hash value is currently stored in the BIOS 102.In the illustrated example, the SMI handler 130 determines whether thehash value 114 of the passphrase interface 112 is anything but null (orany other value representative of a lack of a hash being stored). If so,the example SMI handler 130 determines that the secure sleep state isenabled and that the DRAM 106 is to be encrypted before the sleep stateis entered. The example SMI handler 130 triggers encryption logic 132 toencrypt the DRAM 106. In particular, the encryption logic 132 appliesthe encryption key 124 stored in the BIOS memory 120 to the data of theDRAM 106 using any suitable encryption technique. After the DRAM 106 hasbeen encrypted, the encryption key 124 is destroyed. On the other hand,the wrapped encryption key 122 is preserved. In some examples, the BIOSmemory 120 is not encrypted such that access to the wrapped encryptionkey 122 is possible upon resuming from the secure sleep state.

The example encryption logic 132 also stores an encryption map 134 inthe BIOS memory 120 representative of critical DRAM regions that have tobe decrypted before the OS 104 can be resumed (e.g., from the securesleep state). In particular, the example encryption map 134 of FIG. 1includes information on locations and size of data structures (e.g.,page tables, descriptor tables, and/or other data structures) that willbe needed for the OS 104 to resume and run upon the platform 100. Asdescribed in greater detail below in connection with FIGS. 4 and 5, theexample encryption map 134 can be used in a decryption process performedwhen the platform 100 is being resumed from the secure sleep state.

When the encryption logic 132 has completed the encryption of the DRAM106 and creation of the encryption map 134, the platform 100 is placedin the secure sleep state. The user can resume the platform 100 (e.g.,take the platform 100 out of the secure sleep state) by, for example,opening a lid, pressing a dedicated button, etc. In response to such anaction, the BIOS 102 begins booting the platform 100. The example BIOS102 of FIG. 1 includes a secure sleep state detector 136 to determinewhether the platform 100 is resuming from a secure sleep state or anunsecure sleep state (e.g., with the sleep protection of the DRAM 106provided by the secure sleep state module 108 disabled). In theillustrated example, the secure sleep state detector 136 checks thepassphrase interface 122 for the presence of a hash value. That is, theexample secure sleep state detector 136 of FIG. 1 determines if anythingbut null (or any other value representative of a lack of a hash beingstored) is stored at the hash value 114. The presence of the hash value114 indicates that the secure sleep state is enabled and that the DRAM106 is to be decrypted. The lack of a hash value indicates that thesecure sleep state was not entered and the DRAM does not have to bedecrypted.

When the secure sleep state detector 136 determines that the platform100 is being resumed from the secure sleep state, the example passphraseinterface 112 of FIG. 1 prompts the user for the passphrasecorresponding to the secure sleep state. The entry provided in responseto the prompt is compared to the hash value 114 by a comparator 138. Thecomparator 138 determines whether the user-provided entry is a match ofthe has value 114, which corresponds to the passphrase previouslyprovided by the user to active or enable the secure sleep state. If theuser-provided entry does not match the stored hash value 114, the useris denied access to the platform 100. In some examples, the user may beprovided a set number of tries to enter the correct passphrase.

On the other hand, if the user-provided entry matches the stored hashvalue 114, a decrypter 140 of the example secure sleep state module 108is triggered. The example decrypter 140 decodes the encryption of theDRAM 106 such that the OS 104 has access to the data of the DRAM 106 inthe state in which the DRAM 106 was before the sleep state was entered.A first example implementation of the decrypter 140 is shown in FIG. 2.The example decrypter 140 of FIG. 2 includes a wrapping key deriver 200that re-derives the wrapping key from the passphrase provided by theuser in response to the prompt of the passphrase interface 112. Asdescribed above, the passphrase that was provided by the user toinitiate or activate the secure sleep state was destroyed after beingused to generate the encryption key 124. Therefore, when resuming fromthe secure sleep state, the example wrapping key deriver 200 of thedecrypter 140 uses the passphrase that was provided by the user uponresuming the platform 100, which was determined to match the previouslyprovided passphrase (e.g., via comparison to the stored hash value 114).

The example decrypter 140 of FIG. 2 also includes an unwrapper 202 touse the re-derived wrapping key to unwrap the wrapped encryption key 122of the BIOS memory 120. As described above, the wrapped encryption key122 is preserved after encrypting the DRAM 106 and placing the platformin the secure sleep state such that the encryption key can be unwrappedand used by the decrypter 140 when resuming from the secure sleep state.Thus, the example unwrapper 202 of FIG. 2 uses the preserved wrappedversion 122 of the encryption key and re-derived wrapping key (from thewrapping key deriver 200) to generate the encryption key used by theencryption logic 132 to secure the DRAM 106.

The example decrypter 140 of FIG. 2 includes decryption logic 204 thatuses the obtained encryption key to decrypt the DRAM 106 such that theOS 104 will have access to the DRAM 106 when the BIOS 102 passes controlto the OS 104. After the decryption logic 204 has decrypted the DRAM106, a key destroyer 206 destroys the encryption key used by thedecrypter 140 and the wrapped encryption key 122 of the BIOS memory 120.In some scenarios, the platform 100 may be placed in the sleep statebefore the decryption logic 204 has completed the decryption of the DRAM106. In such instances, the key destroyer 206 does not destroy theencryption key or the wrapped encryption key 122. Rather, the keys arepreserved such that the DRAM 106 can be decrypted when the platform 100is resumed from (second) sleep state.

As the wrapped encryption key 122 is destroyed during the decryptionprocess and the encryption key 124 is destroyed after being used toencrypt the DRAM 106 and after re-deriving the encryption key for use bythe decrypter 140, a new encryption key (different from the previousencryption key) and a new wrapped encryption key are needed for use whenthe platform 100 is again placed in the sleep state (e.g., the next timethe user closes the lid, presses a dedicated sleep button, selects thesleep state from a menu, etc.). Accordingly, the passphrase that wasprovided by the user in response to the prompt of the passphraseinterface 112 to gain access to the platform is used to by the keygenerator 118 to generate a wrapping key. The key generator 118 alsogenerates a random encryption key. Because a random functionality (e.g.,a random number generator) is used to generate the encryption key, theencryption key from one iteration of the secure sleep state is differentfrom another iteration of the secure sleep state (or at least differentfrom the next iteration, as random value may repeat over many, perhapsmillions, of iterations). As before, the wrapping key is used to wrapthe randomly generated encryption key and the wrapped encryption key 122and the encryption key 122 are stored in the BIOS memory 120. Further,as before, the wrapping key and the passphrase are destroyed.

The BIOS 102 then passes control to the OS 104, which is resumed suchthat the platform 100 operates in the state from which the secure sleepstate was entered. As described above, the OS 104 continues to manageoperation of the platform 100 until the power state of the platform 100is changed (e.g., by the user). If the change corresponds to a placementof the platform 100 in the sleep state (e.g., by user action, byreaching an inactivity threshold, etc.), the sleep state detector 126determines whether the secure sleep state is enabled and, if so, theinterrupt generator 128 generates an interrupt that is handled by theSMI handler 130 of the secure sleep state module 108. The example SMIhandler 130 triggers the encrypter 116 to encrypt the DRAM 106 again,this time using the new encryption key 124. The data of the DRAM 106 isprotected once again while the platform 100 is in the sleep state. Thus,the example secure sleep state module 108 provides repeated protectionof the DRAM 106 each time the platform 100 is placed in the sleep state.

While an example manner of implementing the platform 100 has beenillustrated in FIG. 1, one or more of the elements, processes and/ordevices illustrated in FIG. 1 may be combined, divided, re-arranged,omitted, eliminated and/or implemented in any other way. Further, theexample secure sleep state module 108, the example BIOS setup interface110, the example passphrase interface 112, the example encrypter 116,the example key generator 118, the example sleep state detector 126, theexample interrupt generator 128, the example SMI handler 130, theexample encryption logic 132, the example secure sleep state detector136, the example comparator 138, the example decrypter 140 and/or, moregenerally, the example platform 100 of FIG. 1 may be implemented byhardware, software, firmware and/or any combination of hardware,software and/or firmware. Thus, for example, any of the example securesleep state module 108, the example BIOS setup interface 110, theexample passphrase interface 112, the example encrypter 116, the examplekey generator 118, the example sleep state detector 126, the exampleinterrupt generator 128, the example SMI handler 130, the exampleencryption logic 132, the example secure sleep state detector, 136, theexample comparator 138, the example decrypter 140 and/or, moregenerally, the example platform 100 of FIG. 1 could be implemented byone or more circuit(s), programmable processor(s), application specificintegrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s))and/or field programmable logic device(s) (FPLD(s)), etc. When any ofthe appended system or apparatus claims of this patent are read to covera purely software and/or firmware implementation, at least one of theexample secure sleep state module 108, the example BIOS setup interface110, the example passphrase interface 112, the example encrypter 116,the example key generator 118, the example sleep state detector 126, theexample interrupt generator 128, the example SMI handler 130, theexample encryption logic 132, the example secure sleep state detector,136, the example comparator 138, the example decrypter 140 and/or, moregenerally, the example platform 100 of FIG. 1 are hereby expresslydefined to include a tangible computer readable storage medium such as amemory, DVD, CD, Blu-ray, etc. storing the software and/or firmware.Further still, the example platform 100 of FIG. 1 may include one ormore elements, processes and/or devices in addition to, or instead of,those illustrated in FIG. 1, and/or may include more than one of any orall of the illustrated elements, processes and devices.

While an example manner of implementing the decrypter 140 of FIG. 1 hasbeen illustrated in FIG. 2, one or more of the elements, processesand/or devices illustrated in FIG. 2 may be combined, divided,re-arranged, omitted, eliminated and/or implemented in any other way.Further, the example wrapping key deriver 200, the example unwrapper202, the example decryption logic 204, the example key destroyer 206and/or, more generally, the example decrypter 140 of FIG. 2 may beimplemented by hardware, software, firmware and/or any combination ofhardware, software and/or firmware. Thus, for example, any of theexample wrapping key deriver 200, the example unwrapper 202, the exampledecryption logic 204, the example key destroyer 206 and/or, moregenerally, the example decrypter 140 of FIG. 2 could be implemented byone or more circuit(s), programmable processor(s), application specificintegrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s))and/or field programmable logic device(s) (FPLD(s)), etc. When any ofthe appended system or apparatus claims of this patent are read to covera purely software and/or firmware implementation, at least one of theexample wrapping key deriver 200, the example unwrapper 202, the exampledecryption logic 204, the example key destroyer 206 and/or, moregenerally, the example decrypter 140 of FIG. 2 are hereby expresslydefined to include a tangible computer readable storage medium such as amemory, DVD, CD, Blu-ray, etc. storing the software and/or firmware.Further still, the example decrypter 140 of FIG. 2 may include one ormore elements, processes and/or devices in addition to, or instead of,those illustrated in FIG. 2, and/or may include more than one of any orall of the illustrated elements, processes and devices.

FIGS. 3A-D are flowcharts representative of example machine readableinstructions for implementing the example platform 100 of FIGS. 1 and/or2. In the example flowcharts of FIGS. 3A-D, the machine readableinstructions comprise program(s) for execution by a processor such asthe processor 612 shown in the example computer 600 discussed below inconnection with FIG. 6. The program(s) may be embodied in softwarestored on a tangible computer readable medium such as a CD-ROM, a floppydisk, a hard drive, a digital versatile disk (DVD), a Blu-ray disk, or amemory associated with the processor 612, but the entire program and/orparts thereof could alternatively be executed by a device other than theprocessor 612 and/or embodied in firmware or dedicated hardware.Further, although the example program(s) is described with reference tothe flowcharts illustrated in FIGS. 3A-D, many other methods ofimplementing the example platform 100 may alternatively be used. Forexample, the order of execution of the blocks may be changed, and/orsome of the blocks described may be changed, eliminated, or combined.

As mentioned above, the example processes of FIGS. 3A-D may beimplemented using coded instructions (e.g., computer readableinstructions) stored on a tangible computer readable medium such as ahard disk drive, a flash memory, a read-only memory (ROM), a compactdisk (CD), a digital versatile disk (DVD), a cache, a random-accessmemory (RAM) and/or any other storage media in which information isstored for any duration (e.g., for extended time periods, permanently,brief instances, for temporarily buffering, and/or for caching of theinformation). As used herein, the term tangible computer readable mediumis expressly defined to include any type of computer readable storageand to exclude propagating signals. Additionally or alternatively, theexample processes of FIGS. 3A-D may be implemented using codedinstructions (e.g., computer readable instructions) stored on anon-transitory computer readable medium such as a hard disk drive, aflash memory, a read-only memory, a compact disk, a digital versatiledisk, a cache, a random-access memory and/or any other storage media inwhich information is stored for any duration (e.g., for extended timeperiods, permanently, brief instances, for temporarily buffering, and/orfor caching of the information). As used herein, the term non-transitorycomputer readable medium is expressly defined to include any type ofcomputer readable medium and to exclude propagating signals. As usedherein, when the phrase “at least” is used as the transition term in apreamble of a claim, it is open-ended in the same manner as the term“comprising” is open ended. Thus, a claim using “at least” as thetransition term in its preamble may include elements in addition tothose expressly recited in the claim.

FIG. 3A begins with the platform 100 being turned on (e.g., by a user)(block 300). The BIOS 102 is booted to initiate one or more processessuch as, for example, a power-on self test (POST) and/or any othersuitable procedures related to booting the platform 100 (block 302). Ifthe BIOS 102 determines that the platform 100 is being resumed from asleep state (block 304), the example secure sleep state detector 136 ofFIG. 1 determines whether the sleep state from which the platform 100 isbeing resumed is a secure sleep state (block 306). For example, thesecure sleep state detector 136 determines whether a hash value isstored in connection with the passphrase interface 112 of FIG. 1. If thesleep state from which the platform 100 is being resumed is a securesleep state (block 306), control passes to FIG. 3B which is described infurther detail below. If the sleep state from which the platform 100 isbeing resumed is not a secure sleep state (block 306), the OS 104 isresumed (block 308). Further, the OS 104 is executed (block 328) andcontrol passes to FIG. 3C which is described in further detail below.

Referring back to block 304, if the platform 100 is not being resumedfrom a sleep state, the example secure sleep state module 108 determineswhether the secure sleep state provided thereby is currently enabled(block 310). If the secure sleep state is enabled (block 310), controlpasses to FIG. 3B which is described below. If the secure sleep state isnot enabled (block 310), the user may enter the BIOS setup interface 110to enable the secure sleep state. To determine whether the BIOS setupinterface 110 has been activated by the user, a keystroke (e.g., from akeyboard) is captured (block 312). If too much time has passedcorresponding to a timeout (block 314), control proceeds to block 326and the OS 104 is booted. Otherwise, the BIOS setup interface 110determines whether any entered keystroke corresponds to a request toenter the BIOS setup interface 110 (block 316). If not, additionalkeystroke(s) are captured (block 312) and the BIOS 102 again determineswhether a timeout has occurred (block 314).

When the user has engaged the BIOS setup interface 110 (block 316), theBIOS interface 110 presents a menu to the user (block 318). Thepassphrase interface 112 determines whether the user has entered apassphrase into the presented menu to activate or enable the securesleep state functionality disclosed herein (block 320). If no suchpassphrase is entered into the BIOS setup interface 110 (block 320), theOS 104 is booted (block 326) and executed (block 328). On the otherhand, if a passphrase is entered into the BIOS setup interface 110corresponding to an activation of the secure sleep state (block 320),that passphrase is hashed and the resulting hash value 114 is stored(block 322). Furthermore, the key generator 118 of the encrypter 116generates a wrapping key from the passphrase and destroys the passphrase(block 324). Control then passes to FIG. 3D which is described below.

Referring now to FIG. 3B, as described above, control passes to FIG. 3Bwhen the platform 100 is resuming from the secure sleep state (block306) or when the platform 100 is resuming from a state other than thesleep state and the secure sleep state is enabled (block 310). Thus,FIG. 3B begins with the passphrase interface 112 obtaining a passphrasefrom the user (block 330). Because the secure sleep state is enabled,the user is required to enter the correct passphrase to gain access tothe data of the platform 100 (e.g., the DRAM 106). When the passphraseis received from the user, the comparator 138 determines whether theentered passphrase matches the stored hash value 114 (block 332). If thereceived passphrase does not correspond to the stored hash value 114,the user is provided a certain number of tries to re-enter thepassphrase. If the incorrect passphrase has been entered too many times(e.g., exceeding the allowed number of tries) (block 338), the loginprocess is halted (block 340). Further, access to the platform 100 isdenied and the illustrated example ends (block 342).

Referring back to block 332, if the passphrase entered by the usercorresponds to the stored hash value 114, the key generator 118 derivesa wrapping key from the entered passphrase (block 334). Further, theentered passphrase is destroyed (block 336). Control then passes to FIG.3D which is described below.

Regarding FIG. 3C, as described above, control is passed to FIG. 3C whenthe OS 104 has begun running and the platform 100 is executingapplication(s) and/or document(s). In other words, control passes toFIG. 3C when the platform 100 is in an ON state. When in the ON state,the user can decide to place the platform in a sleep state to, forexample, preserve the state of the platform while significantly loweringthe power consumption of the platform 100 for a period of time. To doso, the user can, for example, close a lid, press a dedicated button, orselect the sleep state from a menu managed by the OS 104. When the sleepstate detector 126 determines that the user has taken such an action(block 344), the OS 104 prepares the platform 100 for the sleep stateand writes to corresponding ACPI register (block 346). As describedabove, the write to the ACPI register causes the interrupt generator 128to invoke the SMI handler 130 of the secure sleep state module 108(block 348).

In response, the SMI handler 130 determines whether the secure sleepstate is enabled by checking if there is a hash value stored inconnection with the passphrase interface 112 (or any other componenttasked with storing the hash value 114) (block 350). If the secure sleepstate is not enabled, the SMI handler 130 places the platform 100 intothe sleep state without encrypting the DRAM 106 (block 354). Otherwise,the encryption logic 132 uses the stored encryption key 124 to encryptthe DRAM 106 (block 352). Further, the encryption logic 132 destroys theencryption key 124 but maintains the wrapped encryption key 122 (block352). When the DRAM 106 has been encrypted (block 352), the platform 100is placed in sleep state (block 354). The illustrated example then ends(block 356).

Regarding FIG. 3D, as described above, control is passed to FIG. 3D whena new passphrase has been entered to activate the secure sleep state(blocks 320-324) or when a matching passphrase has been entered at alater time when the platform is resuming (blocks 332-336). In theillustrated example, the secure sleep detector 136 determines whetherthe platform 100 is being resumed from a secure sleep state (block 358).If not, control has arrived at FIG. 3D in response to a new passphrasebeing entered and the DRAM 106 does not need to be decrypted. Otherwise,if the platform 100 is being resumed from the secure sleep state, theDRAM 106 needs to be decrypted. Thus, if it is determined that theplatform 100 is being resumed from the secure sleep state at block 358,the wrapping key deriver 200 re-derives the wrapping key and theunwrapper 202 unwraps the wrapped encryption key 122 (block 360). Usingthe unwrapped encryption key, the decryption logic 204 decrypts the DRAM106 (block 362). Further, if the entire DRAM 106 has been decrypted, thekey destroyer 206 destroys the encryption key 124 used to decrypt theDRAM 106, as well as the wrapped encryption key 122 from which thatencryption key was obtained (block 364). As described above, the keysare preserved if, for example, the platform 100 is placed in the sleepstate before the DRAM 106 is completely decrypted or if the platform 100is placed in any other state (e.g., a hibernation state) before the DRAM106 is completely decrypted. Control then proceeds to block 366. Controlalso proceeds to block 366 from block 358 when it is determined that theplatform 100 is not being resumed from the secure sleep state.

The key generator 118 generates and stores a new random encryption key124 for use in encrypting the DRAM 106 in the event that the platform100 is again placed in the sleep state (block 366). Further, theencryption key 124 is wrapped in the wrapping key generated at block 324or block 334. The wrapped encryption key 122 is stored in the BIOSmemory 120 (block 370). The wrapping key used to generate the wrappedencryption key 122 is destroyed (block 372). The OS 104 is then resumed(block 374) and ran (block 376). Control then passes to FIG. 3C, whichis described above.

FIG. 4 is another example implementation of the decrypter 140 of FIG. 1.Like the example implementation of the decrypter 140 shown in FIG. 2 anddescribed above, the example decrypter 400 of FIG. 4 includes a wrappingkey deriver 402, an unwrapper 404 and a key destroyer 406 that operatesimilarly to the wrapping key deriver 200, the unwrapper 202 and the keydestroyer 206 of FIG. 2 to obtain a key for use in decrypting the DRAM106. However, the example decrypter 400 of FIG. 4 includes differentdecryption logic 408 than the example decrypter 140 of FIG. 2. Inparticular, the example decryption logic 408 of FIG. 4 utilizes avirtual machine monitor (VMM) 410 to enable the decrypter 400 to decryptregions or portion of the DRAM 106 in an on-demand fashion as the OS 104is resuming. Thus, rather than waiting for each encrypted region of theDRAM 106 to be decrypted before passing control from the BIOS 102 to theOS 104 (as described above in connection with FIG. 2), the exampledecrypter 400 of FIG. 4 decrypts certain critical regions of DRAM 106,then allows the OS 104 to resume when the critical regions of the DRAM106 have been decrypted, and then begins decrypting remaining encryptedregions of the DRAM 106 as those regions are accessed by the OS 104. Indoing so, the example decrypter 400 of FIG. 4 addresses additionallatency issues associated with having to decrypt the DRAM 106 whenresuming from the sleep state. For example, the virtualization utilizedby the example decrypter 400 of FIG. 4 enables the OS 104 to resume itsmost critical functionality through decryption of the correspondingregions first and then to decrypt the remaining DRAM 106 in an on-demandfashion or, in other words, as needed by the OS 104. As a result, the OS104 can be resumed and executed, at least partially, without having towait for all of the encrypted regions of the DRAM 106 to be decrypted,which could take a significant amount of time when the DRAM 106 isrelatively large.

When the platform 100 is resuming from the secure sleep state providedby the secure sleep state module 108, the BIOS 102 and the secure sleepstate module 108 perform the initial operations described above inconnection with FIGS. 1-3 to transition the platform 100 to the ONstate, such as re-deriving the encryption key for use in the decryptionprocess (e.g., via the wrapping key deriver 402 and the unwrapper 404).However, in the example of FIG. 4, the decrypter 400 launches the VMM410 to decrypt the DRAM 106. In the illustrated example, the VMM 410 isloaded (e.g., when the secure sleep state is first enabled) into theBIOS memory 120 (e.g., SMRAM) and/or any other memory not accessible tothe OS 104. The example VMM 410 of FIG. 4 is relatively small and islimited to virtualizing the DRAM 106. That is, aside from the DRAM 106,the VMM 410 leaves other components under the control of the OS 104.

To virtualize the DRAM 106, the example VMM 410 includes a DRAMvirtualizer 412. The example DRAM virtualizer 412 virtualizes the DRAM106 using any suitable technique. For example, the DRAM virtualizer 412can virtualize the DRAM 106 via Extended Page Tables (EPTs). When usingEPTs to virtualize the DRAM 106, the DRAM virtualizer 412 creates theEPTs to map guest physical addresses to host physical addresses. Pagetables (PTs) in the OS 104 map linear addresses to guest physicaladdresses. When a program in the OS 104 executes and accesses a linearaddress that is not in the PTs of the OS 104, a Page Fault (#PF) istriggered. In such instances, the #PF is handled by the OS 104. On theother hand, when there is no mapping between the corresponding guestphysical address and a host physical address, an EPT violation istriggered. In the illustrated example, EPT violations are handled by theVMM 410 (rather than the OS 104).

As an alternative to EPTs, the example DRAM virtualizer 412 canvirtualize the DRAM 106 via a virtual Translation Lookaside Buffer(TLB). When using a virtual TLB to virtualize the DRAM 106, the DRAMvirtualizer 412 creates a copy of the PTs of the OS 104 and uses #PFsand/or other triggers to keep the copy consistent with the correspondingversion in the OS 104. Similar to EPT violations described above, #PFsindicate to the VMM 410 that guest physical addresses are not mapped tohost physical addresses when a virtual TLB has been used to virtualizethe DRAM 106.

Thus, when the DRAM virtualizer 412 uses EPTs to virtualize the DRAM106, EPT violations indicate that the VMM 410 needs to decrypt acorresponding region of the DRAM 106. In other words, when the DRAMvirtualizer 412 uses EPTs to virtualize the DRAM 106, EPT violations(resulting from the OS 104 accessing a particular (encrypted) address ofthe DRAM 106) trigger the VMM 410 to handle the exception such that theparticular address of the DRAM 106 is decrypted for use by the OS 104.Similarly, when the DRAM virtualizer 412 uses a virtual TLB tovirtualize the DRAM 106, #PFs indicate that the VMM 410 needs to decrypta corresponding region of the DRAM 106. In other words, when the DRAMvirtualizer 412 uses a virtual TLB to virtualize the DRAM 106, #PFs(resulting from the OS 104 accessing a particular (encrypted) address ofthe DRAM 106) trigger the VMM 410 to handle the exception such that theparticular address of the DRAM 106 is decrypted for use by the OS 104.Additional or alternative types of virtualization and/or triggers can beutilized by the example VMM 410 to virtualize the DRAM 106 and/or totrigger the VMM 410 to handle an instance of the OS 104 trying to accessan encrypted region of the DRAM 106 and, thus, a need to decrypt theDRAM 106.

In the illustrated example, when the VMM 410 is initially launched, thefirst region(s) of the DRAM 106 to be decrypted are the critical regionstracked in the encryption map 134 described above in connection withFIG. 1. The encryption map 134 indicates which regions of the DRAM 106correspond to the critical regions of the DRAM 106, such as the regionsneeded by the OS 104 to initiate or begin resuming. The example VMM 410utilizes the encryption map 134 to decrypt the critical regions suchthat the OS 104 can resume and begin executing. When the VMM 410decrypts a region of the DRAM 106, the decrypted regions are stored indecryption mappings 414. As described above, the decryption mapping 414can include, for example, an EPT, a virtual TLB or whichever type ofvirtualization table is being used by the DRAM virtualizer 412 tovirtualize the DRAM 106. In other words, as regions of the DRAM 106 aredecrypted, those regions are added to the decryption mappings 414. Thus,the decryption mappings 414 track which regions of the DRAM 106 havebeen decrypted.

In the illustrated example, when the critical region(s) of the DRAM 106have been decrypted the OS 104 begins executing. Execution of the OS 104includes attempting to access (e.g., read from and/or write to) certainaddresses in the DRAM 106. As described above, when the OS 104 attemptsto access an address in DRAM 106 that has not yet been decrypted, atrigger will be generated. In the illustrated example, such a trigger isgenerated when the decryption mappings 414 do not include an entrycorresponding to the address that the OS 104 attempted to access. Forexample, when the decryption mappings 414 are implemented via EPTs, anEPT violation (e.g., a trigger) results from the OS 104 attempting toaccess an address that does not (yet) have a corresponding entry in theEPTs. Alternatively, when the decryption mappings 414 are implementedvia a virtual TLB, a #PF (e.g., a trigger) results from the OS 104attempting to access an address that does not (yet) have a correspondingentry in the virtual TLB. The example VMM 410 includes a triggerdetector 416 that detects such triggers. When the example triggerdetector 416 determines that the OS 104 has accessed (or tried toaccess) particular region(s) of the DRAM 106 that have not yet beendecrypted (and, thus, do not have a corresponding entry in thedecryption mappings 414), the example VMM 410 decrypts those region(s)of the DRAM 106. As described above, the encryption key used to encryptthe DRAM 106 is re-derived by the wrapping key deriver 402 and theunwrapper 404. In the illustrated example, the VMM 410 and thedecryption logic 408 of FIG. 4 use the re-derived encryption key todecrypt the region(s) of the DRAM 106 that caused the correspondingtrigger. That is, the VMM 410 enables the example decrypter 400 of FIG.4 to decrypt regions of the DRAM 106 as the OS 104 accesses thoseregions (e.g., in an on-demand manner). When the region(s) of the DRAM106 corresponding to the current trigger have been decrypted, thedecryption mappings 414 are updated to include entries mapped to thoseregion(s). For example, when the DRAM virtualizer 412 uses EPTs tovirtualize the DRAM 106, the decrypted region(s) of the DRAM 106 areadded to the EPTs. Alternatively, when the DRAM virtualizer 412 uses avirtual TLB to virtualize the DRAM 106, the decrypted region(s) of theDRAM 106 are added to the PTs of the TLB.

In some examples, rather than adding entries to the decryption mappings414 as the DRAM 106 is decrypted and triggering the VMM 410 to decryptthe DRAM 106 when the OS 104 attempts to access a region not having anentry in the decryption mappings 414, the example decrypter 400 canutilize a bit designated to indicate whether a corresponding region inDRAM 106 is still encrypted. In particular, the decryption mappings 414can be generated at the onset of the decryption process to reflect theencrypted DRAM 106 by including corresponding entries for each of theregions of the encrypted DRAM 106. Further, a bit can be added to theentries of the PTs of the decryption mappings 414. When the bit for aparticular region is set (e.g., to ‘1’ or true), that region is stillencrypted. On the other hand, when the bit for a particular region isnot set (e.g., ‘0’ or false), that region has been decrypted. In suchinstances, when the OS 104 attempts to access a region of the DRAM 106,the corresponding bit is checked. If the bit is set, a trigger (e.g., anEPT violation or a #PF) is generated and, thus, the corresponding regionof the DRAM 106 is decrypted. If the bit is not set, no decryption isnecessary because the corresponding region of the DRAM 106 is no longerencrypted.

When all of the encrypted regions of the DRAM 106 have been decrypted(e.g., during an iteration of the platform 100 resuming from the securesleep state), the VMM 410 passes control to the OS 104, therebycompleting the resuming of the OS 104 from the secure sleep state. Insome examples, a mechanism is used to ensure that the DRAM 106 isdecrypted within a certain (e.g., predefined) period of time. Forexample, the VMM 410 of FIG. 4 includes a time constraint enforcer 418that includes an adjustable or fixed period of time corresponding to atime limit for decrypting the DRAM 106 in the on-demand manner describedabove. In other words, the example time constraint enforcer 418 allowsthe VMM 410 to, for the defined period of time, decrypt the DRAM 106region by region as the OS 104 accesses different portions of the DRAM106. If the defined period of time has expired and the entire DRAM 106has not been decrypted, the example time constraint enforcer 418 causethe decryption logic 408 to begin decrypting the DRAM 106 without regardto access attempts by the OS 104. As a result, even portions of the DRAM106 that the OS 104 has not yet tried to access since being resumed fromthe secure sleep state will be decrypted when the period of time hasexpired.

In some examples, enforcement of the time limit by the time constraintenforcer 418 includes setting a VMX-preemption timer associated with theVMM 410. In particular, the VMX-preemption timer can be set toperiodically transfer control to the VMM 410 to enable the VMM 410 todecrypt the DRAM 106 in a predefined manner (e.g., the numerically nextaddress(es) in an encrypted address space of the DRAM 106). As a result,the VMM 410 decrypts region(s) of the DRAM 106 after each revolution ofthe VMX-preemption timer of the time constraint enforcer 418 in additionto the on-demand decryption of the DRAM 106 (e.g., in response to a EPTviolation or a #PF). Thus, the DRAM 106 is eventually decrypted withinthe period of time even when the OS 104 is not accessing the DRAM 106and, thus, not triggering decryption.

Additionally or alternatively, enforcement of the time limit by the timeconstraint enforcer 418 can utilize one or more idle loops of the OS104. Such loops are implemented with interrupt instructions (e.g., STIs)followed by a halt instruction (e.g., HLT), which halts the OS 104 untilthe next external interrupt occurs. In such instances, when a haltinstruction is issued in connection with the OS 104, the VMM 410 canreceive control and, thus, be able to decrypt region(s) of the DRAM 106,until the next interrupt is triggered. Such an approach allows the VMM410 to decrypt regions of the DRAM 106 when the OS 104 is not busy,thereby avoiding using resources when the OS 104 is busy.

The size(s) of the pages mapped in the EPTs or the virtual TLB can beany suitable size such as, for example, 4 k, 2 MB, 1 GB, etc. A smallerpage size results in shorter decryption time each time a trigger (e.g.,an EPT violation or a #PF) occurs, but also results in a longer overalltime before the entire DRAM 106 is decrypted. In the illustratedexample, the decrypter 140 sets the size(s) of the pages based onheuristics such as, for example, DRAM size, CPU speed, DRAM speed, busspeed, etc.

While an example manner of implementing the decrypter 140 of FIG. 1 hasbeen illustrated in FIG. 4, one or more of the elements, processesand/or devices illustrated in FIG. 4 may be combined, divided,re-arranged, omitted, eliminated and/or implemented in any other way.Further, the example wrapping key deriver 402, the example unwrapper404, the example key destroyer 406, the example decryption logic 408,the example VMM 410, the example DRAM virtualizer 412, the exampledecryption mappings 414, the example trigger detector 416, the exampletime constraint enforcer 418 and/or, more generally, the exampledecrypter 400 of FIG. 4 may be implemented by hardware, software,firmware and/or any combination of hardware, software and/or firmware.Thus, for example, any of the example wrapping key deriver 402, theexample unwrapper 404, the example key destroyer 406, the exampledecryption logic 408, the example VMM 410, the example DRAM virtualizer412, the example decryption mappings 414, the example trigger detector416, the example time constraint enforcer 418 and/or, more generally,the example decrypter 400 of FIG. 4 could be implemented by one or morecircuit(s), programmable processor(s), application specific integratedcircuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or fieldprogrammable logic device(s) (FPLD(s)), etc. When any of the appendedsystem or apparatus claims of this patent are read to cover a purelysoftware and/or firmware implementation, at least one of the examplewrapping key deriver 402, the example unwrapper 404, the example keydestroyer 406, the example decryption logic 408, the example VMM 410,the example DRAM virtualizer 412, the example decryption mappings 414,the example trigger detector 416, the example time constraint enforcer418 and/or, more generally, the example decrypter 400 of FIG. 4 arehereby expressly defined to include a tangible computer readable storagemedium such as a memory, DVD, CD, Blu-ray, etc. storing the softwareand/or firmware. Further still, the example decrypter 400 of FIG. 4 mayinclude one or more elements, processes and/or devices in addition to,or instead of, those illustrated in FIG. 4, and/or may include more thanone of any or all of the illustrated elements, processes and devices.

FIG. 5 is a flowchart representative of example machine readableinstructions for implementing the example decrypter 400 of FIG. 4. Inthe example flowchart of FIG. 5, the machine readable instructionscomprise program(s) for execution by a processor such as the processor612 shown in the example computer 600 discussed below in connection withFIG. 6. The program(s) may be embodied in software stored on a tangiblecomputer readable medium such as a CD-ROM, a floppy disk, a hard drive,a digital versatile disk (DVD), a Blu-ray disk, or a memory associatedwith the processor 612, but the entire program and/or parts thereofcould alternatively be executed by a device other than the processor 612and/or embodied in firmware or dedicated hardware. Further, although theexample program(s) is described with reference to the flowchartillustrated in FIG. 5, many other methods of implementing the exampledecrypter 400 of FIG. 4 may alternatively be used. For example, theorder of execution of the blocks may be changed, and/or some of theblocks described may be changed, eliminated, or combined.

As mentioned above, the example processes of FIG. 5 may be implementedusing coded instructions (e.g., computer readable instructions) storedon a tangible computer readable medium such as a hard disk drive, aflash memory, a read-only memory (ROM), a compact disk (CD), a digitalversatile disk (DVD), a cache, a random-access memory (RAM) and/or anyother storage media in which information is stored for any duration(e.g., for extended time periods, permanently, brief instances, fortemporarily buffering, and/or for caching of the information). As usedherein, the term tangible computer readable medium is expressly definedto include any type of computer readable storage and to excludepropagating signals. Additionally or alternatively, the exampleprocesses of FIG. 5 may be implemented using coded instructions (e.g.,computer readable instructions) stored on a non-transitory computerreadable medium such as a hard disk drive, a flash memory, a read-onlymemory, a compact disk, a digital versatile disk, a cache, arandom-access memory and/or any other storage media in which informationis stored for any duration (e.g., for extended time periods,permanently, brief instances, for temporarily buffering, and/or forcaching of the information). As used herein, the term non-transitorycomputer readable medium is expressly defined to include any type ofcomputer readable medium and to exclude propagating signals. As usedherein, when the phrase “at least” is used as the transition term in apreamble of a claim, it is open-ended in the same manner as the term“comprising” is open ended. Thus, a claim using “at least” as thetransition term in its preamble may include elements in addition tothose expressly recited in the claim.

FIG. 5 begins with an indication that the computing platform 100 is totransition from the secure sleep state disclosed herein to an ON state(block 500). The BIOS 102 prepares the platform 100 to resume from thesecure sleep state by, for example, loading one or more drivers and/ortests needed to resume the platform 100 (block 502). When the BIOS 102determines that decryption of the DRAM 106 is to be performed, controlis passed to the VMM 410 (block 504). The DRAM virtualizer 412virtualizes the DRAM 106 using any suitable technique such as, forexample, EPTs or a virtual TLB, as described above (block 506). Further,in the illustrated example of FIG. 5, the time constraint enforcer 418sets up a timer that will cause the OS 104 to periodically transfercontrol to the VMM 410 (block 506). As described above, the periodictransfer of control to the VMM 410 enforces a time limit for the DRAM106 to be decrypted.

When the DRAM 106 has been virtualized (e.g., and the virtualizationtables have been stored in the decryption mappings 414), the VMM 410 andthe decryption logic 408 decrypt the critical region(s) of the DRAM 106(block 508). The critical region(s), which represent portions of theDRAM 106 that are needed for the OS 104 to begin assuming control of theplatform 100, are tracked in the encryption mapping 134 created uponencryption of the DRAM 106. The decryption of the critical region(s) isadded to the decryption mappings 414 so that the decrypter 400 can trackwhich parts of the DRAM 106 have been decrypted thus far.

The platform 100 then resumes and runs the OS 104 (block 512 and 514).That is, the OS 104 begins handling normal operation of the document(s)and/or application(s), the state of which was preserved during thesecure sleep state. As the OS 104 executes instructions, a trigger(e.g., an EPT violation or a #PF) may occur when the OS 104 attempts toaccess encrypted portion(s) of the DRAM 106, or a periodic time intervalset up by the time constraint enforcer 418 may expire. In suchinstances, the OS 104 incurs an exit and control is passed to the VMM410 (block 516). If control has passed to the VMM 410 due to avirtualization fault (e.g., an EPT violation or a #PF) (block 518), thecorresponding faulting region(s) of the DRAM 106 are decrypted (block526). If the decryption mappings 414 indicate that encrypted region(s)of the DRAM 106 remain (block 528), control passes to block 510).Otherwise, if the entire DRAM 106 has been decrypted (block 528), thevirtualization process is ended (block 530) and the example of FIG. 5ends (block 532).

Referring back to block 518, if the exit from the OS 104 does notcorrespond to a virtualization fault, the VMM 410 decrypts region(s) ofthe DRAM 106 (e.g., the next sequential encrypted region(s) according toan address space organization) (block 520). As described above, such anexit from the OS 104 may correspond to, for example, an expiration ofthe VMX-preemption timer or an indication that the OS 104 is idle. Whenthe VMM 410 has decrypted the intended region(s) of the DRAM (e.g., whenthe exit from the OS 104 corresponded to an expiration of the timer) orwhen an interrupt occurs in the OS 104 (e.g., when the exit from the OS104 corresponded to the OS 104 being idle) (block 522), control passesto block 528. Otherwise, if the VMM 410 has more region(s) of the DRAM410 to decrypt (e.g., when the exit from the OS 104 corresponded to anexpiration of the timer) or when no interrupt has occurred in the OS 104(e.g., when the exit from the OS 104 corresponded to the OS 104 beingidle) (block 522), the decryption of the region(s) of the DRAM 106 isadded to the decryption mappings 414 (block 524) and control returns toblock 520.

FIG. 6 is a block diagram of a processor platform 600 capable ofexecuting the instructions of FIGS. 3A-3D to implement the exampleplatform 100 of FIGS. 1 and 2 and/or the instructions of FIG. 5 toimplement the example decrypter 400 of FIG. 4. The processor platform600 can be, for example, a server, a personal computer, an Internetappliance, a DVD player, a CD player, a Blu-ray player, a gamingconsole, a personal video recorder, a smart phone, a tablet, a printer,or any other type of computing device.

The processor platform 600 of the instant example includes a processor612. For example, the processor 612 can be implemented by one or moremicroprocessors or controllers from any desired family or manufacturer.

The processor 612 includes a local memory 613 (e.g., a cache) and is incommunication with a main memory including a volatile memory 614 and anon-volatile memory 616 via a bus 618. The volatile memory 614 may beimplemented by Synchronous Dynamic Random Access Memory (SDRAM), DynamicRandom Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM)and/or any other type of random access memory device. The non-volatilememory 616 may be implemented by flash memory and/or any other desiredtype of memory device. Access to the main memory 614, 616 is controlledby a memory controller.

The processor platform 600 also includes an interface circuit 620. Theinterface circuit 620 may be implemented by any type of interfacestandard, such as an Ethernet interface, a universal serial bus (USB),and/or a PCI express interface.

One or more input devices 622 are connected to the interface circuit620. The input device(s) 622 permit a user to enter data and commandsinto the processor 612. The input device(s) can be implemented by, forexample, a keyboard, a mouse, a touchscreen, a track-pad, a trackball,isopoint and/or a voice recognition system.

One or more output devices 624 are also connected to the interfacecircuit 620. The output devices 624 can be implemented, for example, bydisplay devices (e.g., a liquid crystal display, a cathode ray tubedisplay (CRT), a printer and/or speakers). The interface circuit 620,thus, typically includes a graphics driver card.

The interface circuit 620 also includes a communication device such as amodem or network interface card to facilitate exchange of data withexternal computers via a network 626 (e.g., an Ethernet connection, adigital subscriber line (DSL), a telephone line, coaxial cable, acellular telephone system, etc.).

The processor platform 600 also includes one or more mass storagedevices 628 for storing software and data. Examples of such mass storagedevices 628 include floppy disk drives, hard drive disks, compact diskdrives and digital versatile disk (DVD) drives.

The coded instructions 632 of FIG. 3A-3D and/or 5 may be stored in themass storage device 628, in the volatile memory 614, in the non-volatilememory 616, and/or on a removable storage medium such as a CD or DVD.

Example methods include, in response to an initiation of a sleep stateof a computing platform, encrypting a memory of the computing platform,and decrypting the memory when resuming the computing platform from thesleep state, wherein placing the computing platform in the sleep stateincludes powering down a portion of the computing platform andpreserving a state of the computing platform.

Some example methods further include using a passphrase to generate awrapping key to wrap a randomly generated encryption key to form awrapped encryption key.

Some example methods further include destroying the passphrase aftergenerating the wrapping key and before encrypting the memory with theencryption key.

Some example methods further include destroying the encryption key andpreserving the wrapped encryption key after encrypting the memory. Theexample method may also include verifying a correct passphrase prior todecrypting the memory.

Some example methods further include, when resuming from the sleepstate, deriving an encryption key based on the passphrase and a storedwrapped encryption key.

In some example methods, decrypting the memory includes virtualizing theencrypted memory.

Some example methods further include decrypting a first portion of thememory in response to an operating system attempting to access the firstportion of the memory that is encrypted.

Some example methods further include decrypting a second portion of thememory in response to the operating system being idle.

Some example methods further include decrypting a second portion of thememory in response to a predefined period of time ending.

Example tangible machine readable storage media include instructionsthat, when executed, cause a machine to at least, in response to aninitiation of a sleep state of a computing platform, encrypt a memory ofthe computing platform; and decrypt the memory when resuming thecomputing platform from the sleep state, wherein placing the computingplatform in the sleep state includes powering down a portion of thecomputing platform and preserving a state of the computing platform.

In some examples, the instructions cause the machine to use a passphraseto generate a wrapping key to wrap a randomly generated encryption keyto form a wrapped encryption key.

In some examples, the instructions cause the machine to destroy thepassphrase after generating the wrapping key and before encrypting thememory with the encryption key.

In some examples, the instructions cause the machine to destroy theencryption key and preserve the wrapped encryption key after encryptingthe memory.

In some examples, the instructions cause the machine to verify a correctpassphrase prior to decrypting the memory.

In some examples, the instructions cause the machine to, when resumingfrom the sleep state, derive an encryption key based on the passphraseand a stored wrapped encryption key.

In some examples, the instructions cause the machine to decrypt thememory by virtualizing the encrypted memory.

In some examples, the instructions cause the machine to decrypt thememory by decrypting a first portion of the memory in response to anoperating system attempting to access the first portion of the memorythat is encrypted.

In some examples, the instructions cause the machine to decrypt thememory by decrypting a second portion of the memory in response to theoperating system being idle.

Example apparatus include a detector to determine that a computingplatform is to be placed in a sleep state, wherein a current state ofthe computing platform is to be preserved during the sleep state; and anencrypter to encrypt a memory of the computing platform in the currentstate when the detector detects an initiation of the sleep state; and adecrypter to decrypt the memory when resuming the computing platformfrom the sleep state.

Some example apparatus further include a key generator to use apassphrase to generate a wrapping key to wrap a randomly generatedencryption key to form a wrapped encryption key, the passphrase to bedestroyed after generation of the wrapping key and before encryption ofthe memory with the encryption key.

In some example apparatus, the encryption key may be destroyed and thewrapped encryption key may be preserved after encryption of the memory.

In some example apparatus, the decrypter, when resuming from the sleepstate, is to derive an encryption key using a passphrase provided by auser and a stored wrapped encryption key.

In some example apparatus, the decrypter is to decrypt the memory bydecrypting a first portion of the memory in response to an operatingsystem attempting to access the first portion of the memory that isencrypted.

In some example apparatus, the decrypter is to decrypt the memory bydecrypting a second portion of the memory in response to the operatingsystem being idle.

Although certain example apparatus, methods, and articles of manufacturehave been disclosed herein, the scope of coverage of this patent is notlimited thereto. On the contrary, this patent covers all apparatus,methods, and articles of manufacture fairly falling within the scope ofthe claims of this patent.

1. A method, comprising: in response to an initiation of a sleep stateof a computing platform, encrypting a memory of the computing platformby: generating a wrapping key based on a user-provided passphrase;wrapping a randomly generated encryption key with the wrapping key toform a wrapped encryption key; and decrypting the memory using thewrapped encryption key when resuming the computing platform from thesleep state, wherein initiating the sleep state includes powering down aportion of the computing platform and preserving a state of thecomputing platform.
 2. (canceled)
 3. A method as defined in claim 1,further comprising destroying the passphrase after generating thewrapping key and before encrypting the memory with the randomlygenerated encryption key.
 4. A method as defined in claim 1, furthercomprising destroying the randomly generated encryption key andpreserving the wrapped encryption key after encrypting the memory.
 5. Amethod as defined in claim 1, further comprising verifying a correctpassphrase input prior to decrypting the memory.
 6. A method as definedin claim 5, further comprising, when resuming from the sleep state,deriving the encryption key based on the passphrase input and thewrapped encryption key.
 7. A method as defined in claim 1, whereindecrypting the memory includes virtualizing the encrypted memory.
 8. Amethod as defined in claim 1, further comprising decrypting a firstportion of the memory in response to an operating system attempting toaccess the first portion of the memory that is encrypted.
 9. A method asdefined in claim 8, further comprising decrypting a second portion ofthe memory in response to the operating system being idle.
 10. A methodas defined in claim 8, further comprising decrypting a second portion ofthe memory in response to a predefined period of time ending.
 11. Atangible computer readable storage medium comprising instructions that,when executed, cause a machine to at least: in response to an initiationof a sleep state of a computing platform, encrypt a memory of thecomputing platform by: generating a wrapping key based on auser-provided passphrase, and wrapping a randomly generated encryptionkey with the wrapping key to form a wrapped encryption key; and decryptthe memory using the wrapped encryption key when exiting the sleepstate, wherein initiating the sleep state includes powering down aportion of the computing platform and preserving a state of thecomputing platform.
 12. (canceled)
 13. A tangible computer readablestorage medium as defined in claim 11, the instructions to cause themachine to destroy the passphrase after generating the wrapping key andbefore encrypting the memory with the randomly generated encryption key.14. A tangible computer readable storage medium as defined in claim 11,the instructions to cause the machine to destroy the randomly generatedencryption key and preserve the wrapped encryption key after encryptingthe memory.
 15. A tangible computer readable storage medium as definedin claim 11, the instructions to cause the machine to verify a correctpassphrase entry corresponding to the passphrase prior to decrypting thememory.
 16. A tangible computer readable storage medium as defined inclaim 15, the instructions to cause the machine to, when exiting thesleep state, derive an encryption key based on the passphrase entry andthe wrapped encryption key.
 17. A tangible computer readable storagemedium as defined in claim 11, the instructions to cause the machine todecrypt the memory by virtualizing the encrypted memory.
 18. A tangiblecomputer readable storage medium as defined in claim 11, theinstructions to cause the machine to decrypt the memory by decrypting afirst portion of the memory in response to an operating systemattempting to access the first portion of the memory that is encrypted.19. A tangible computer readable storage medium as defined in claim 18,the instructions to cause the machine to decrypt the memory bydecrypting a second portion of the memory in response to the operatingsystem being idle.
 20. An apparatus, comprising: a detector to determinethat a computing platform is to be placed in a sleep state, wherein acurrent state of the computing platform is to be preserved during thesleep state; an encrypter to encrypt a memory of the computing platformin the current state in response to the detector detecting that thecomputing platform is to be placed in the sleep state by: generating awrapping key based on a user-provided passphrase, and wrapping arandomly generated encryption key with the wrapping key to form awrapped encryption key; and a decrypter to decrypt the memory when thecomputing platform leaves the sleep state, wherein at least one of thedetector, the encrypter, or the decrypter is implemented via a logiccircuit.
 21. An apparatus as defined in claim 20, wherein the encrypteris to destroy the passphrase after generation of the wrapping key andbefore encryption of the memory with the randomly generated encryptionkey.
 22. An apparatus as defined in claim 20, wherein the decrypter isto destroy the randomly generated encryption key, and wherein theencrypter is to preserve the wrapped encryption key after encryption ofthe memory.
 23. An apparatus as defined in claim 20, wherein thedecrypter is to, when resuming from the sleep state, derive the randomlygenerated encryption key using a passphrase input provided by a user andthe wrapped encryption key.
 24. An apparatus as defined in claim 20,wherein the decrypter is to decrypt the memory by decrypting a firstportion of the memory in response to an operating system attempting toaccess the first portion of the memory that is encrypted.
 25. Anapparatus as defined in claim 25, wherein the decrypter is to decryptthe memory by decrypting a second portion of the memory in response tothe operating system being idle.
 26. A method as defined in claim 1,further comprising, in response to the initiation of placing thecomputing platform in the sleep state, requesting a user to enter theuser-provided passphrase.
 27. A tangible computer readable storagemedium as defined in claim 11, the instructions to cause the machine to,in response to the initiation of placing the computing platform in thesleep state, request a user to enter the user-provided passphrase.